@rvagg @SgtPooki : I think it's time to get new release out given some of the new functionality. That said, I think the current release description (which will populate the release) by default is underselling the changes. Some extra editorizling is needed here. I know we don't have a changelog, but I assume we'll put that in the release page.

So a couple of things:

1. Anything else we should be waiting for? (I would bias to just have another followup release by default, but maybe there are reasons not to?)
2. Anyone already started on the release documentation? I can take it if needed (but I would like to use as much of my focus time for operational items/planning).

I want #354 in before this is out

there's a changelog, the answer to editorialising is to edit it directly in this PR and that's what gets merged

I'll touch this up once #354 is in and get it out straight away.

Thanks @rvagg - sounds good.

I know we don't have a changelog,

Doh - I misspoke. Thanks for correcting me.

Reminder for myself on how this works (please correct me if this is wrong): any changelog edits in the 0.18 changelog section we make right now in this PR will get overridden when #354 lands, hence the reason we wait to editorialize afterwards but before merging this PR.

@BigLep I think that's right, or if we edit it ourselves maybe it won't get auto-updated. I'm not a pro with release-please. But; when we edit it here in this PR, it'll be merged as is and that text should be used for the notes in the GitHub release 🤞.

I've made changes, will merge when green.

🤖 Created releases:

• v0.18.0

🌻

CHANGELOG text didn't make it to the release; I've manually edited that. Will have to investigate whether this can be configured because I thought this was the default behaviour.